1. Field of the Invention
The present invention relates to data telecommunications and more particularly to data transfer mechanisms for serial communications interfaces.
2. State of the Art
Personal computers and computer workstations with modems now access a wide variety of networks. Although, from the standpoint of a user, data transfer using a modem may appear to be relatively simple, the actual data transfer operation may be considerably involved. For example, as between the computer and the modem, the rate at which one device generates data and the rate at which the other device is able to process data will generally not coincide. This non-coincidence of data rates necessitates the use of device buffers and flow control to pace data transfer between the two devices. Flow control assures that one device does not overflow the data buffer of the other device.
In the direction from the modem to the computer, the computer may become busy with other tasks besides the data transfer task, such that its allocated data buffers become full. The computer will then send an indication to the modem that the computer cannot presently accept any more data. Data may then be buffered up in the modem until the computer is ready to accept more data, or the indication that the computer has stopped receiving data may be propagated upstream to the far-end modem and the far-end computer such that the far-end computer temporarily stops sending data.
In the other direction from the computer to the modem, the modem may perform data compression such that the data rate from the computer to the modem may exceed the physical data rate across the data link from the modem to the far-end modem. To take full advantage of data compression, the data rate from the computer to the modem should exceed the maximum data rate on the data link to the far-end modem, such that the compressed data fully occupies the available bandwidth, or nearly so. The data compression ratio that the modem can achieve varies, however, with the characteristics of the data. The modem must therefore be able to invoke flow control to control the data rate from the computer to the modem as the attainable data compression ratio varies.
Flow control is generally of one of two types, software flow control and hardware flow control.
In software flow control, typically, two special control characters are defined, an "XON" character that signals a device to begin or resume transmission and an "XOFF" character that signals a device to stop transmission. Each data byte received is checked to see if it is XON or XOFF. When XON or XOFF is detected, a software interrupt routine is initiated to take the appropriate action. Because of interrupt latency, data transmission may continue for a period of milliseconds before being stopped. A "high-water mark/low-water mark" strategy is therefore employed, in accordance with which an XOFF character is sent by a device when its buffer is still some number of bytes short of being full, or overflowing, and an XON character is sent by the device when its buffer is still some number of bytes short of being empty. Software flow control is generally only suitable for ASCII data in which the XON and XOFF byte patterns may be reserved. In the case of arbitrary binary data, in which the byte patterns are unconstrained, the XON and XOFF byte patterns might occur in the data itself, which would result in unpredictable behavior if software flow control were used.
In hardware flow control, dedicated signals, for example Request to Send (RTS) and Clear to Send (CTS), are used to signal a device to start or stop transmission of data. However, as in software flow control, occurrence of one of these signals typically causes an interrupt which is then serviced in an interrupt routine. Therefore, although the overhead of checking each byte for a control character is avoided, interrupt latency still requires the use of a high-water mark/low-water mark buffering scheme.
Although modem communications is generally adequate for exchanging text files, the transmission of voice, fax and video data, especially simultaneous, requires a data rate that exceeds the capabilities of most modems. Furthermore, in the case of voice and video data, the transmission of such "isochronous streams" requires that the data be delivered to its destination in an uninterrupted flow. Such streams may be not only isochronous (i.e., constant bit rate) but also "real-time." Real-time data streams are generated continuously during the course of an event and transmitted with minimum delay to the destination. To handle real-time and isochronous data streams using conventional methods of data transfer and flow control would require sizable (and hence costly) device buffers and would entail a great deal of CPU intervention.
To achieve a low-cost telecommunications device capable of handling real-time and isochronous data streams, a data transfer mechanism is needed that overcomes the foregoing disadvantages. Furthermore, a data transfer mechanism is needed that can efficiently accommodate any of various telecommunications devices having a range of capabilities and data rates.